These were buried in pelias/schema (https://github.com/pelias/schema/blob/f28002db187f1685abc3688b141e0bfdd5cdd01a/settings.js#L289-L296),
so by moving them here it's more obvious they can be overridden.

We use 1 shard as a default in development where scalability isn't
required.

Also, because we use the [dfs_query_then_fetch](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-search-type.html#dfs-query-then-fetch)
search mode, having one shard eliminates any possibility of queries run
_without_ that setting having confusing results due to TF/IDF

The `index_concurrency` setting is set to 10 as an attempt to increase
indexing performance as well.

Reference:
https://github.com/pelias/api/blob/9ff383cc2b4a690fa05a88e70c598bfdc28751f4/controller/search.js#L44
https://www.elastic.co/guide/en/elasticsearch/guide/current/relevance-is-broken.html

Connects pelias/schema#178

This default was buried in our private chef configuration. Because
Pelias is generally run with a bulk indexin phase before any queries are
run, a higher refresh interval makes sense to improve indexing
performance.

Reference links:
https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-update-settings.html#bulk
https://sematext.com/blog/2013/07/08/elasticsearch-refresh-interval-vs-indexing-performance/